Date: Sat, 23 Apr 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #75 To: tcp-group-digest TCP-Group Digest Sat, 23 Apr 94 Volume 94 : Issue 75 Today's Topics: BBS Suggestions (was RE: MX record problem) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 22 Apr 1994 16:58:25 -0600 From: jra1854@tntech.edu (Jeffrey Austen) Subject: BBS Suggestions (was RE: MX record problem) To: nos-bbs@hydra.carleton.ca, tcp-group@ucsd.edu >> This whole BBS/TCP thing really works against us. Yes the ISH is going >> obsolete the whole thing very quickly. > >a) I doubt the ISH will effect the Packet BBS community much. > >b) The ISH is a US project and will do bugger all for the rest of us. (The >local Internet access point wants to bring volume charges) Maybe ISH won't affect packet much, but it should. And yes, it will affect the rest of the world. * FLAME ON * How long has packet and packet BBSs been around? About ten years. What progress has been made in that time? Not much. Do we have a method for easily integrating BBS and internet traffic? NO! Can a packet BBS function well in an emergency operation environment? NO! Aren't emergency services and advancing the state of the art two primary justifications for Amateur Radio? YES! * FLAME OFF * Here are three (four?) concrete suggestions to consider: (1) Make the BBS BID field size sufficiently long to accomodate usenet and Internet IDs. This will allow news posts to be entered into the packet network at multiple points without the creation of redundant messages. (2) Create a message priority field which can be used to designate, at a minimum, the following priority levels: bulletin, normal, priority, emergency. Make the BBS code forward messages according to priority. High priority messages should be forwarded immediately without waiting for the normal forwarding time; when the "emergency bit" is set low priority (i.e., bulletin) forwarding should be slowed or cease. (3a) Expand the address field of the BBS to accomodate inter-network mail using the normal construct. E.g., "jra1854%tntech.edu@gateway.w4efq.#midtn.tn.noam" or "k9ja%w4efq.#midtn.tn.noam@internet.gateway.host.com". This will allow proper operation of the two networks as independent entities and the sending of messages between them using specified gateways. Eventually, I'd like to see the name space of the two networks converge but it doesn't look like that will happen for a long time. (3b) Make sure that we have an unambiguous definition for the allowable "top-level" names in the BBS network which are mutually exclusive from those used in the Internet. E.g., NOAM instead of NA. This will allow the automatic trapping of misaddressed mail rather than sending it to Namibia; it will also be a step towards converging the name spaces. Jeff, k9ja +-+ Jeffrey Austen | Tennessee Technological University jra1854@tntech.edu | Box 5004 (615) 372-3485 | Cookeville Tennessee 38505 U.S.A. ------------------------------ End of TCP-Group Digest V94 #75 ******************************